On Saturday, March 8th, 2025 at 2:49 PM, Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > what happens is that the second loop only considers memory regions that were found to be available during the first loop. Ah, I see what the intention is now. Sorry I missed that. > What firmware are you using? U-Boot 2025.04-rc3 which I use to load systemd-boot which then tries to load the kernel. > Can you share the contents of the EFI memory map? This is the memory map at power-on (before systemd-boot has loaded): lmb_dump_all: memory.count = 0x1 memory[0] [0x0-0x3fffffff], 0x40000000 bytes, flags: none reserved.count = 0x4 reserved[0] [0x4000000-0x41fffff], 0x200000 bytes, flags: no-map reserved[1] [0x4400000-0x53fffff], 0x1000000 bytes, flags: no-map reserved[2] [0x3eaf3000-0x3eaf5fff], 0x3000 bytes, flags: no-notify, no-overwrite reserved[3] [0x3eaf6950-0x3fffffff], 0x15096b0 bytes, flags: no-overwrite When efi_allocate_pages() is first called, U-Boot reports the memory map looks like this: lmb_dump_all: memory.count = 0x1 memory[0] [0x0-0x3fffffff], 0x40000000 bytes, flags: none reserved.count = 0x5 reserved[0] [0x4000000-0x41fffff], 0x200000 bytes, flags: none reserved[1] [0x4400000-0x53fffff], 0x1000000 bytes, flags: none reserved[2] [0x3dae6000-0x3e2cbfff], 0x7e6000 bytes, flags: no-overwrite, no-map reserved[3] [0x3ea6f000-0x3eaf0fff], 0x82000 bytes, flags: no-overwrite, no-map reserved[4] [0x3eaf1960-0x3fffffff], 0x150e6a0 bytes, flags: no-map It also seems like when it makes that first call it is asking for 4,416 pages at address 0x3faf1138. It seemed to me like this was inside an already reserved range which I assumed is why U-Boot returns EFI_NOT_FOUND.
