On Tue, 2026-02-24 at 11:05 -0600, Tom Rini wrote: > [...] > So one thing I'd like to know is what makes your case different, so that > we can catch it in testing in the future. > [...] > I'm guessing in your failure case we're doing some huge allocation this > second time here and that's why there's not space later on for the > device tree? But it's also a little odd that in your ramdisk is now > being moved around, but perhaps that's because we detected an overlap > now? Can you share how exactly you're making this failure happen please? > Thanks.
The test case I used is u-boot master built with just qemu_arm64_defconfig and a simple fit image that contains a gzip compressed kernel_noload and a ramdisk to boot¹. The rpi test case has no ramdisk. Also I didn't want to specify any load addresses in the fit image to make the image generic. Yes, there is a huge allocation taking place when loading the ramdisk. The qemu default env does not have "initrd_high" set² so boot_ramdisk_high() stays with "initrd_copy_to_ram = 1" and calls lmb_alloc_mem() to move the ramdisk. cu Ludwig [1]https://github.com/lnussel/initrd-minimal-experiment/blob/arm/kernel.its.aarch64 [2] initrd_high used to be set to 0xffffffff for qemu. IIUC this value of -1 is supposed to turn the loading feature off and use the ramdisk in place (even though the comment in the source says 0 turns it off). Commit eb726cf6ae0 removed the setting. So always moving things around now. Anyway this setting can't have worked for 64bit systems as it's not -1 there. So confusing :-) -- (o_ Ludwig Nussel //\ Siemens AG V_/_ www.siemens.com
