On Wed, Feb 25, 2026 at 01:19:12PM +0000, Nussel, Ludwig wrote: > 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.
Thanks for explaining. Yes, the ramdisk being present is what leads to the failure here, I can see with a test image on the Pi a new LMB reservation of: reserved[1] [0x1000000-0x39dfffff], 0x38e00000 bytes, flags: none which means we then get a failure over the ramdisk I added. I'll look at this more and see if I have suggestions over your initial patch. -- Tom
signature.asc
Description: PGP signature
