On Tue, 5 Aug 2025 at 15:11, Tomas Alvarez Vanoli <tomas.alvarez-van...@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 >
