lmb_alloc_base() is just calling lmb_alloc_base_flags() with LMB_NONE.
There's not much we gain from this abstraction, so let's remove the
former add the flags argument to lmb_alloc_base() and make the code
a bit easier to follow.
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
Tested-by: Sam Protsenko <semen.protsenko@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
(cherry picked from commit 3075708017)
lmb_alloc_addr() is just calling lmb_alloc_addr_flags() with LMB_NONE
There's not much we gain from this abstraction, so let's remove the
latter, add a flags argument to lmb_alloc_addr() and make the code a
bit easier to follow.
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
Tested-by: Sam Protsenko <semen.protsenko@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
(cherry picked from commit 15e0c5e390)
A bisect of Ubuntu 2022.04 boot-failure on qemu-x86_64 resulted in this
patch. I am not sure how to investigate it.
The boot hangs at some point during booting of the install image, before
the Ubuntu logo appears.
I will sent a series with a script showing how it is run.
Series-to: u-boot
Series-cc: sughosh, trini
This reverts commit a68c9ac5d8.
When running U-Boot as an EFI payload with CONFIG_EFI_STUB, the reserved
regions from the previous stage EFI bootloader should be carried over
since they may not fully align with the reserved-memory regions in
devicetree.
Implement a helper to map these pages when the EFI subsystem starts up.
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
An EFI app expects pointers to be returned, cast to u64. The conversion
to use addresses missed this, so fix the call.
Signed-off-by: Simon Glass <sjg@chromium.org>
Update a few memory functions to log their inputs and outputs. To avoid
the use of 'goto', etc. the functions are turned into stubs, calling a
separate function to do the actual operation.
Add a few tests.
Signed-off-by: Simon Glass <sjg@chromium.org>
This collects together several v3 patches into one, to avoid any
temporary test-breakage which would make future bisecting difficult.
For efi_memory, the efi_allocate_pool() call uses a pointer to refer to
memory, but efi_allocate_pages() uses an int. This causes quite a bit of
confusion, since sandbox has a distinction between pointers and
addresses. Adjust efi_allocate/free_pages_ext() to handle the
conversions.
Update efi_add_memory_map() function and its friend to use an address
rather than a pointer cast to an integer.
For lmb, now that efi_add_memory_map_pg() uses a address rather than a
pointer cast to an int, we can simplify the code here.
For efi_reserve_memory(), use addresses rather than pointers, so that it
doesn't have to use mapmem.
In general this simplifies the code, but the main benefit is that casts
are no-longer needed in most places, so the compiler can check that we
are doing the right thing.
For efi_add_runtime_mmio(), now that efi_add_memory_map() takes an
address rather than a pointer, do the mapping in this function.
Update the memset() parameter to be a char while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
This cannot work since the code is not present in the emulated memory.
In any case, sandbox cannot make use of the runtime code.
For now, just drop it from sandbox. We can always adjust things to copy
it into memory, if needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
The word 'physical' suggests that there is an associated virtual address
but there is not. Use 'base' since this is the base address of a region.
Change some uint64_t and remove some brackets to keep checkpatch happy.
Signed-off-by: Simon Glass <sjg@chromium.org>
This struct is really a node in the list, not a list itself. Also it
doesn't need an efi_ prefix. Rename it.
Signed-off-by: Simon Glass <sjg@chromium.org>
We don't need a separate struct for the values in this node. Move
everything in together, so that there is just one struct to consider.
Add a comment about physical_start, so it is clear that it is really
a pointer.
Signed-off-by: Simon Glass <sjg@chromium.org>
This field is always the same as physical_start, so keeping track of it
separately is unnecessary and confusing. Drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present efi_memory uses struct efi_mem_desc for each node of its
memory list. This is convenient but is not ideal, since:
- it means that the fields are under a 'desc' sub-structure
- it includes an unused 'reserved' field
- it includes virtual_start which is confusing as it is always the same
as physical_start
- we must use u64 to store pointers, since that is how they are returned
by calls to efi_get_memory_map()
As a first step to tidying this up, create a new, private struct to hold
these fields.
Signed-off-by: Simon Glass <sjg@chromium.org>
Exported functions should be documented in the header file, not the
implementation. We tend to make such updates on a piecemeal basis to
avoid a 'flag day'. Move some comments related to memory allocation to
follow the convention.
Signed-off-by: Simon Glass <sjg@chromium.org>
There is quite a bit of confusion in the EFI code as to whether a field
contains an address or a pointer. As a first step towards resolving
this, document the memory-descriptor struct, indicating that it holds
pointers, not addresses.
Dro the same for efi_add_memory_map() as it is widely used, as well as
efi_add_memory_map_pg() which is only used by lmb
Signed-off-by: Simon Glass <sjg@chromium.org>
We never free and unmap the memory on errors and we never unmap it when
freeing it. The latter won't cause any problems even on sandbox, but for
consistency always use unmap_sysmem()
Fixes: commit 22f2c9ed9f ("efi: memory: use the lmb API's for allocating and freeing memory")
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
We currently call efi_free_pages() with a notify flag and explicitly
update the efi memory map. That's not needed as lmb_free_flags() will do
that for us if the LMB_NONOTIFY flag is removed
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
lmb_alloc_flags() & lmb_alloc_base_flags() are just a wrappers for
_lmb_alloc_base(). Since the only difference is the max address of the
allowed allocation which _lmb_alloc_base() already supports with the
LMB_ALLOC_ANYWHERE flag, remove one of them.
Keep the lmb_alloc_base_flags() which also prints an error on failures
and adjust efi_allocate_pages() to only use one of them.
While at it clean up the duplicate function description from the header
file.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
The variable overlap_only_ram is used to specify that the new memory
region that is being created needs to come from the free memory pool
-- this is done by carving out the memory region from the free
memory. The name is a bit confusing though, as other allocated memory
regions, like boot-services code and data are also part of the RAM
memory. Rename the variable to overlap_conventional to highlight the
fact that it is the free/conventional memory that is being referred to
in this context.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
The EFI_CONVENTIONAL_MEMORY type, which is the usable RAM memory is
now being managed by the LMB module. Remove the addition of this
memory type to the EFI memory map. This memory now gets added to the
EFI memory map as part of the LMB memory map update event handler.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
The memory region occupied by U-Boot is reserved by LMB, and gets
added to the EFI memory map through a call from the LMB module. Remove
this superfluous addition to the EFI memory map.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
In U-Boot, LMB and EFI are two primary modules who provide memory
allocation and reservation API's. Both these modules operate with the
same regions of memory for allocations. Use the LMB memory map update
event to notify other interested listeners about a change in it's
memory map. This can then be used by the other module to keep track of
available and used memory.
There is no need to send these notifications when the LMB module is
being unit-tested. Add a flag to the lmb structure to indicate if the
memory map is being used for tests, and suppress sending any
notifications when running these unit tests.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Use the LMB API's for allocating and freeing up memory. With this, the
LMB module becomes the common backend for managing non U-Boot image
memory that might be requested by other modules.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Use the list_for_each_entry() API to get the efi_mem_list node
directly, instead of making an additional call to list_entry().
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Populate the previous memory descriptor node pointer only after it's
parent struct has been initialised. The compiler fixes this logic to
do the right thing, but it is better to have correct code in place.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
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>
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>
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>
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: 7b78d6438a ("efi_loader: Reserve unaccessible memory")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
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>
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>
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>
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>
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>
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>
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>
