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

Sughosh Ganu sughosh.ganu at linaro.org
Tue Aug 5 14:07:20 CEST 2025


On Tue, 5 Aug 2025 at 17:00, Tomas Alvarez Vanoli
<tomas.alvarez-vanoli at hitachienergy.com> wrote:
>
> >I am confused here. You mention above that the address of the rootfs is determined based on its size. So you do know the memory that would be needed for the rootfs? Also, how does calculating the amount of RAM left over for the kernel help. I mean, what if the kernel is bigger than the amount of >left over memory? Can that not happen if you don't know the amount of memory that would be needed for the kernel as you mention above.
>
> Sorry, maybe I misused the term "kernel memory". I am referring to the amount of physical ram available for the kernel to use:
>
> From the kernel parameter docs:
>
> ```
>         mem=nn[KMG]     [KNL,BOOT] Force usage of a specific amount of memory
>                         Amount of memory to be used when the kernel is not able
>                         to see the whole system memory or for test.
>                         [X86] Work as limiting max address. Use together
>                         with memmap= to avoid physical address space collisions.
>                         Without memmap= PCI devices could be placed at addresses
>                         belonging to unused RAM.
> ```
>
> We know the memory that is needed based for the rootfs "in runtime", it's not something we can compile into u-boot (if you add a new binary to the rootfs then it's bigger).
> We don't want the kernel to be touching this piece of memory that emulates the mtd partition.
>
> I hope this clears up the usecase.

Okay, I see. Given that we now have a global memory map for lmb, I
don't think that using lmb functionality is the best way of computing
the amount of memory that would be available for the kernel to use.
Please note that with a global and persistent memory map of lmb, there
is no guarantee as to where the first chunk of used memory lie above
your rootfs memory. Earlier, I think this was fine as the lmb memory
map was local, so you could copy the ramfs to some low memory region,
and then show the rest of memory as available in the lmb memory map.
That might no longer be the case. So this computation of memory
available for the kernel will have to be re-designed. I think instead
of relying on the lmb memory map for your computations, there should
be some fixed memory region where the ramfs would have to be copied,
and then the rest of the memory can be considered as safe for the
kernel to use.

Btw, I tried looking for the function that you are changing in your
board file in the patch, but I do not see it in the upstream U-Boot.

-sughosh

>
> Tomas


More information about the U-Boot mailing list