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

[Tomas Alvarez Vanoli]

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.
 
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