[RFC 0/1] use lmb to calculate ram left for the kernel

[Sughosh Ganu]

On Tue, 5 Aug 2025 at 15:11, Tomas Alvarez Vanoli
<tomas.alvarez-vanoli at hitachienergy.com> wrote:
>
> Hi all,
>
> We recently updated from 2024.01 to 2025.07 and the changes in the lmb lib
> required us to add some custom code to it.
>
> I would like to ask for your opinion on if we are overcomplicating this or if
> it would make sense to add this functionality to it.
>
> We have a booting mode in which we load a root filesystem in the memory and use
> it to emulate an mtd device.
>
> For this, we were using the lmb library to calculate how much ram was left for
> the kernel, based on the size of the rootfs and other reserved regions.
>
> In the 2024 version the lmb library was working with user lmb tables, so we
> were able to create it, initialize it and then do the calculations there
> without any of the tftp allocs bothering us.
>
> We were just allocating a part of the memory for the rootfs and then using
> `lmb_get_free_size` at the start of the memory to get the kernel memory.
>
> After the update, the table is globally shared, so now there's regions of
> memory allocated by tftpboot (but with no flags).
>
> To work around this, we copied the `lmb_get_free_size` and created
> `lmb_get_reservable_size`, which is the same except it counts as free any
> contiguous memory regions with no flags (see patch).
>
> The functionality could also be extracted to be in a generic function that
> takes 'allowed' flags as an argument.

Do you know what would be the size of memory that the kernel would be
occupying? If you do, the memory allocation API, lmb_alloc_mem() can
be used instead. This function will ensure that the memory returned
will not be overlapping with any other memory in use.

-sughosh

>
> Our platform is armv8, our lmb table looks like this at boot time:
>
> ```
> reserved[0]       [0x83000000-0x83a9afff], 0xa9b000 bytes, flags: none
> reserved[1]       [0x90000000-0x9077e417], 0x77e418 bytes, flags: none
> reserved[2]       [0x93000000-0x930089d3], 0x89d4 bytes, flags: none
> reserved[3]       [0xf3113180-0xf51fffff], 0x20ece80 bytes, flags: no-overwrite
> reserved[4]       [0xf54fc000-0xf7dfbfff], 0x2900000 bytes, flags: none
> reserved[5]       [0xf7dfe000-0xfbdfffff], 0x4002000 bytes, flags: no-notify, no-overwrite
> ```
> Where  0 to 2 are allocated by tftp, 4 is where the root file system is loaded,
> and 3 and 5 are added during the init of the lmb.
>
> Is there a better way to calculate the available memory for the kernel that we
> might be missing?
>
> Would it otherwise make sense to update the lmb library to cover this usecase?
>
> Tomas Alvarez Vanoli (1):
>   lib: lmb: add lmb_get_reservable_size, fix ramfs
>
>  board/keymile/common/common.c | 10 ++++++++--
>  include/lmb.h                 |  1 +
>  lib/lmb.c                     | 31 +++++++++++++++++++++++++++++++
>  3 files changed, 40 insertions(+), 2 deletions(-)
>
> --
> 2.43.0
>