Hi Sughosh,
On Mon, 29 Jul 2024 at 01:50, Sughosh Ganu sughosh.ganu@linaro.org wrote:
On Fri, 26 Jul 2024 at 05:02, Simon Glass sjg@chromium.org wrote:
Hi Sughosh,
On Wed, 24 Jul 2024 at 00:03, Sughosh Ganu sughosh.ganu@linaro.org wrote:
The current LMB API's for allocating and reserving memory use a per-caller based memory view. Memory allocated by a caller can then be overwritten by another caller. Make these allocations and reservations persistent using the alloced list data structure.
Two alloced lists are declared -- one for the available(free) memory, and one for the used memory. Once full, the list can then be extended at runtime.
Signed-off-by: Sughosh Ganu sughosh.ganu@linaro.org
Changes since rfc:
- Squash patches 9 - 11, 13 from the rfc v2 series into a single patch to make it bisectable.
arch/arc/lib/cache.c | 4 +- arch/arm/lib/stack.c | 4 +- arch/arm/mach-apple/board.c | 17 +- arch/arm/mach-snapdragon/board.c | 17 +- arch/arm/mach-stm32mp/dram_init.c | 8 +- arch/arm/mach-stm32mp/stm32mp1/cpu.c | 6 +- arch/m68k/lib/bootm.c | 7 +- arch/microblaze/lib/bootm.c | 4 +- arch/mips/lib/bootm.c | 11 +- arch/nios2/lib/bootm.c | 4 +- arch/powerpc/cpu/mpc85xx/mp.c | 4 +- arch/powerpc/include/asm/mp.h | 4 +- arch/powerpc/lib/bootm.c | 14 +- arch/riscv/lib/bootm.c | 4 +- arch/sh/lib/bootm.c | 4 +- arch/x86/lib/bootm.c | 4 +- arch/xtensa/lib/bootm.c | 4 +- board/xilinx/common/board.c | 8 +- boot/bootm.c | 26 +- boot/bootm_os.c | 5 +- boot/image-board.c | 34 +-- boot/image-fdt.c | 36 ++- cmd/bdinfo.c | 6 +- cmd/booti.c | 2 +- cmd/bootz.c | 2 +- cmd/elf.c | 2 +- cmd/load.c | 7 +- drivers/iommu/apple_dart.c | 8 +- drivers/iommu/sandbox_iommu.c | 16 +- fs/fs.c | 7 +- include/image.h | 28 +- include/lmb.h | 114 +++----- lib/efi_loader/efi_dt_fixup.c | 2 +- lib/efi_loader/efi_helper.c | 2 +- lib/lmb.c | 395 +++++++++++++++------------ net/tftp.c | 5 +- net/wget.c | 5 +- test/cmd/bdinfo.c | 2 +- test/lib/lmb.c | 205 ++++++-------- 39 files changed, 477 insertions(+), 560 deletions(-)
I might have missed it, but I didn't see a response to my comment on the previous patch. I think we should have the lmb state in a struct so that sandbox tests can reset it as needed.
Based on your comment [1], my understanding was that you were okay with not introducing a struct for this. I believe Tom too was not very keen on including the lmb struct into gd.
It should be in a struct, so that its state is all in one place...for testing if nothing else.
Re gd, it doesn't need to be in there, if there is only one.
Regards, Simon