Ben reports a failure to boot the kernel on hardware that starts its
physical memory from 0x0.
The reason is that lmb_alloc_addr(), which is supposed to reserve a
specific address, takes the address as the first argument, but then also
returns the address for success or failure and treats 0 as a failure.
Since we already know the address change the prototype to return an int.
Reported-by: Ben Schneider <ben@bens.haus>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: Ben Schneider <ben@bens.haus>
Reviewed-by: Sughosh Ganu <sughosh.ganu@linaro.org>
The actual logic to allocate a region of memory is in the
_lmb_alloc_base() function. The lmb_alloc() API function calls
lmb_alloc_base(), which then calls _lmb_alloc_base() to do the
allocation. Instead, call the _lmb_alloc_base() directly from both the
allocation API's, and move the error message to the _lmb_alloc_base().
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
The functions to check if the two said regions are adjacent or overlap
are pretty similar in nature. Club the functionality into a single
function lmb_regions_check() and return the appropriate return value
to signify this aspect.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
U-Boot allows re-use of already reserved memory through the
lmb_reserve() and lmb_alloc_addr() API's. This memory re-use is
allowed only when the flag of the existing reserved region and that of
the requested region is LMB_NONE. A check was put in the
lmb_add_region_flags() in commit 8b8b35a4f5 to handle the scenario
where an already reserved region was re-requested with region flag
other than LMB_NONE -- the function then returns -EEXIST in such a
scenario.
The lmb_reserve() function now does a check for a reservation request
with existing reserved regions, and returns -EEXIST in case of an
overlap but when the flag check fails. Remove this now redundant check
from lmb_add_region_flags().
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
The lmb_add_region_flags() first checks if the new region to be added
can be coalesced with existing regions. The check stops if the two
regions are adjecent but their flags do not match. However, it is
possible that the newly added region might be adjacent with the next
existing region and with matching flags. Check for this possibility by
not breaking out of the loop.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
The lmb_fix_over_lap_regions() function is called if the added region
overlaps with an existing region. The function then fixes the overlap
and removes the redundant region. However, it makes certain
assumptions. One assumption is that the overlap would not encompass
the existing region. Another assumption is that the overlap only
occurs between two regions -- the scenario of the added region
overlapping multiple existing regions is not being handled. Handle
these cases by instead calling lmb_resize_regions(). Also remove the
now superfluous lmb_fix_over_lap_regions().
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
The logic used in lmb_alloc() takes into consideration the existing
reserved regions, and ensures that the allocated region does not
overlap with any existing allocated regions. The lmb_reserve()
function is not doing any such checks -- the requested region might
overlap with an existing region. This also shows up with
lmb_alloc_addr() as this function ends up calling lmb_reserve().
Add a function which checks if the region requested is overlapping
with an existing reserved region, and allow for the reservation to
happen only if both the regions have LMB_NONE flag, which allows
re-requesting of the region. In any other scenario of an overlap, have
lmb_reserve() return -EEXIST, implying that the requested region is
already reserved.
Add corresponding test cases which check for overlapping reservation
requests made through lmb_reserve() and lmb_alloc_addr(). And while
here, fix some of the comments in the test function being touched.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
When building with qemu_arm64_defconfig with CONFIG_CC_OPTIMIZE_FOR_DEBUG=y
and CONFIG_EFI_LOADER=n an error undefined reference to efi_add_memory_map_pg
occurs.
Move the EFI dependent part of lmb_map_update_notify() to the EFI
sub-system.
Reported-by: Liya Huang <1425075683@qq.com>
Acked-by: Liya Huang <1425075683@qq.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Instead of testing the value of parameter op at runtime use an enum to
ensure that only valid values are used.
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
lmb_alloc_addr_flags() is a wrapper for _lmb_alloc_addr() and it's the
only function using it. Rename _lmb_alloc_addr() to lmb_alloc_addr_flags()
and remove the wrapper.
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>
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>
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>
There's no point defining a function that's called only once just to
avoid passing the flags. Remove the wrapper and just call
lmb_add_region_flags().
Acked-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
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>
free_mem is a misnomer. We never update it with the free memory for
LMB. Instead, it describes all available memory and is checked against
used_mem to decide whether an area is free or not.
So let's rename this field to better match its usage.
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>
lmb_reserve() is just calling lmb_reserve_flags() with LMB_NONE.
There's not much we gain from this abstraction.
So let's remove the latter, add the flags argument to lmb_reserve()
and make the code a bit easier to follow.
Reviewed-by: Tom Rini <trini@konsulko.com>
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>
LMB flags is not an enum anymore. It's currently used as a bitmask
in various places of our code. So make it a u32 which is more
appropriate when dealing with masks.
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>
We already have a macro for this. Use it instead of adding yet another
variant for alignment.
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>
Fix warnings from kernel-doc script. Improve and unify overall style of
kernel-doc comments in lmb source files. Move all kernel-doc comments
for public functions into the header, as recommended in U-Boot
documentation [1]:
Non-trivial functions should have a comment which describes what
they do. If it is an exported function, put the comment in the
header file so the API is in one place. If it is a static function,
put it in the C file.
This also takes care of existing duplication. While at it, do a bit of
cosmetic cleanups as well.
No functional change.
[1] doc/develop/codingstyle.rst
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
flag_str[] is a pointer to const. Make it also a const pointer. Improve
a style a bit while a it, to make this line fit 80 characters limit.
No functional change.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
rgnflags variable in lmb_add_region_flags() has incorrect type: it's
declared as phys_size_t when it should be enum lmb_flags. That
copy-paste mistake was firstly introduced in commit 59c0ea5df3 ("lmb:
Add support of flags for no-map properties"), and then copied further
into commit ed17a33fed ("lmb: make LMB memory map persistent and
global"). Fix it by using the correct type to match struct lmb_region
field.
No functional change.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Acked-by: Sughosh Ganu <sughosh.ganu@linaro.org>
An attempt to add the already added LMB region using
lmb_add_region_flags() ends up in lmb_addrs_overlap() check, which
eventually leads to either returning 0 if 'flags' is LMB_NONE, or -1
otherwise. It makes it impossible for the user of this function to catch
the case when the region is already added and differentiate it from
regular errors. That in turn may lead to incorrect error handling in the
caller code, like reporting misleading errors or interrupting the normal
code path where it could be treated as the normal case. An example is
boot_fdt_reserve_region() function, which might be called twice (e.g.
during board startup in initr_lmb(), and then during 'booti' command
booting the OS), thus trying to reserve exactly the same memory regions
described in the device tree twice, which produces an error message on
second call.
Return -EEXIST error code in case when the added region exists and it's
not LMB_NONE; for LMB_NONE return 0, to conform to unit tests
(specifically test_alloc_addr() in test/lib/lmb.c) and the preferred
behavior described in commit 1d9aa4a283 ("lmb: Fix the allocation of
overlapping memory areas with !LMB_NONE"). The change of
lmb_add_region_flags() return values is described in the table below:
Return case Pre-1d9 1d9 New
-----------------------------------------------------------
Added successfully 0 0 0
Failed to add -1 -1 -1
Already added, flags == LMB_NONE 0 0 0
Already added, flags != LMB_NONE 0 -1 -EEXIST
Rework all affected functions and their documentation. Also fix the
corresponding unit test which checks reserving the same region with the
same flags to account for the changed return value.
No functional change is intended (by this patch itself).
Fixes: 1d9aa4a283 ("lmb: Fix the allocation of overlapping memory areas with !LMB_NONE")
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: Michal Simek <michal.simek@amd.com>
There are platforms which set the value of ram_top based on certain
restrictions that the platform might have in accessing memory above
ram_top, even when the memory region is in the same DRAM bank. So,
even though the LMB allocator works as expected, when trying to
allocate memory above ram_top, prohibit this by marking all memory
above ram_top as reserved, even if the said memory region is from the
same bank.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Tested-by: Andreas Schwab <schwab@suse.de>
At the moment the LMB allocator will return 'success' immediately on two
consecutive allocations if the second one is smaller and the flags match
without resizing the reserved area.
This is problematic for two reasons, first of all the new updated
allocation won't update the size and we end up holding more memory than
needed, but most importantly it breaks the EFI SCT tests since EFI
now allocates via LMB.
More specifically when EFI requests a specific address twice with the
EFI_ALLOCATE_ADDRESS flag set, the first allocation will succeed and
update the EFI memory map. Due to the LMB behavior the second allocation
will also succeed but the address ranges are already in the EFI memory
map due the first allocation. EFI will then fail to update the memory map,
returning EFI_OUT_OF_RESOURCES instead of EFI_NOT_FOUND which break EFI
conformance.
So let's remove the fast check with is problematic anyway and leave LMB
resize and calculate address properly. LMB will now
- try to resize the reservations for LMB_NONE
- return -1 if the memory is not LMB_NONE and already reserved
The LMB code needs some cleanup in that part, but since we are close to
2025.01 do the easy fix and plan to refactor it later.
Also update the dm tests with the new behavior.
Fixes: commit 22f2c9ed9f ("efi: memory: use the lmb API's for allocating and freeing memory")
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
In the message string " %s[%d]\t[0x%llx-0x%llx], 0x%08llx bytes flags: "
a comma is missing before flags.
To avoid increasing the code size replace '0x%' by '%#'.
Printing the size with leading zeros but not the addresses does not really
make sense. Remove the leading zeros from the size output.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
[trini: Fix test/cmd/bdinfo.c for these changes]
Signed-off-by: Tom Rini <trini@konsulko.com>
Commit c3cf0dc64f ("lmb: add a check to prevent memory overrun")
addressed a possible buffer overrun using assert_noisy().
Resetting via panic() in lmb_print_region() while allowing invalid
lmb flags elsewhere is not reasonable.
Instead of panicking print a message indicating the problem.
fls() returns an int. Using a u64 for bitpos does not match.
Use int instead.
fls() takes an int as argument. Using 1ull << bitpos generates a u64.
Use 1u << bitpos instead.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Acked-by: Sughosh Ganu <sughosh.ganu@linaro.org>
These functions can be used with struct lmb pointers and will be used to
manage IOVA space in the apple_dart iommu driver. This restores part of
the pointer base struct lmb API from before commit ed17a33fed ("lmb:
make LMB memory map persistent and global").
io_lmb_add() and io_lmb_free() can trivially reuse exisiting lmb
functions. io_lmb_setup() is separate for unique error log messages.
io_lmb_alloc() is a simplified copy of _lmb_alloc_base() since the
later has unused features and internal use of the global LMB memory map.
Signed-off-by: Janne Grunau <j@jannau.net>
Low lovel LMB functionality will be used to manage IOVA space in the
Apple dart iommu driver. This reordering ensures that those function
can not access the global LMB memory map variable.
Signed-off-by: Janne Grunau <j@jannau.net>
It will be re-used with a lmb list pointer as argument for IOVA
allocations in the apple_dart iommu driver.
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Janne Grunau <j@jannau.net>
There is already a defined stack-size which is used to reserve space for
the stack. It is confusing to add more in the lmb module, since then the
memory map (with meminfo command) seems to have a hole in it.
Drop this unnecessary feature.
Signed-off-by: Simon Glass <sjg@chromium.org>
Function lmb_map_update_notify() is always referenced.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
We never unmap the memory used to update the EFI memory map after
notifications
Fixes: commit 2f6191526a ("lmb: notify of any changes to the LMB memory map")
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>
We never call lmb_map_update_notify() without checking the result of
lmb_should_notify(). Instead of running that function everytime fold it
in there and add the additional flags parameter
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
The function description says this should return 0 or -1 on failures.
When regions coalesce though this returns the number of coalescedregions
which is confusing and requires special handling of the return code.
On top of that no one is using the number of coalesced regions.
So let's just return 0 on success and adjust our selftests accordingly
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org>
When printing the LMB flags for a memory region, there is a need to
check that the array index that is computed is a sane value. Put a
noisy assert in case this check fails, as that implies something with
the LMB code is not working as expected.
Reported-by: Coverity (CID 510463)
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Provide a way to access this data structure so that the meminfo command
can use it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
lmb_add_region() returns a positive integer if the added regions causes
existing regions to be coalesced. We still want to notify the EFI
subsystem about these added regions though, so adjust lmb_add() to only
bail on errors.
This fixes EFI memory allocation on boards with adjacent memory banks as is the
case on several Qualcomm boards like the RB3 Gen 2.
Fixes: 2f6191526a (lmb: notify of any changes to the LMB memory map)
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
Reviewed-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Tested-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
A bunch of static functions in the LMB module have used a
double-undersore for the function names. It was suggested to use a
single-underscore instead, as the double-underscore is usually used
by library functions. Replace the double-underscore with
single-underscore for all functions.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Suggested-by: Simon Glass <sjg@chromium.org>
The EFI memory allocations are now being done through the LMB
module. With this change, there is no need to get the EFI memory map
and set aside EFI allocated memory.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Some architectures have special or unique aspects which need
consideration when adding memory ranges to the list of available
memory map. Enable this config in such scenarios which allow
architectures and boards to define their own memory map.
Signed-off-by: Sughosh Ganu <sughosh.ganu@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>
U-Boot does not use memory above ram_top. However, this memory does
need to get registered as part of the memory map, so that subsystems
like EFI pass it on to the operating system as part of the EFI memory
map. Add memory above ram_top and reserve it with the LMB_NOOVERWRITE
flag so that it does not get allocated or re-used.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Suggested-by: Mark Kettenis <kettenis@openbsd.org>
Add a flag LMB_NONOTIFY that can be passed to the LMB API's for
reserving memory. This will then result in no notification being sent
from the LMB module for the changes to the LMB's memory map.
While here, also add a description of the memory attributes that the
flags signify.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
The LMB module is to be used as a backend for allocating and freeing
up memory requested from other modules like EFI. These memory requests
are different from the typical LMB reservations in that memory
required by the EFI module cannot be overwritten, or re-requested. Add
versions of the LMB API functions with flags for allocating and
freeing up memory. The caller can then use these API's for specifying
the type of memory that is required. For now, these functions will be
used by the EFI memory module.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Instead of printing the LMB flags as numerical values, print them as
strings. This makes it easier to understand what flags are associated
with the lmb region. Also make corresponding changes to the bdinfo
command's test code.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
The board_lmb_reserve() function is not being used, and currently
there is only an empty weak function defined. Remove this unused
function.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
All of the current definitions of arch_lmb_reserve() are doing the
same thing -- reserve the region of memory occupied by U-Boot,
starting from the current stack address to the ram_top. Introduce a
function lmb_reserve_uboot_region() which does this, and do away with
the arch_lmb_reserve() function.
Instead of using the current value of stack pointer for starting the
reserved region, have a fixed value, considering the stack size config
value.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
