riscv: v2025.10-rc2 fails on QEMU with "Failed to reserve memory for fdt"

[Auer, Lukas]

Hi Sughosh,

On Wed, 2025-08-13 at 14:46 +0530, Sughosh Ganu wrote:
> On Wed, 13 Aug 2025 at 14:20, Vivian Wang <wangruikang at iscas.ac.cn> wrote:
> > 
> > Hi Sughosh,
> > 
> > On 8/13/25 15:58, Sughosh Ganu wrote:
> > > On Tue, 12 Aug 2025 at 20:47, Vivian Wang <wangruikang at iscas.ac.cn> wrote:
> > > > [...]
> > > > 
> > > > Retrieving file: /Image
> > > > Moving Image from 0x84000000 to 0x80200000, end=0x81e88000
> > > > ## Flattened Device Tree blob at bee8f640
> > > >   Booting using the fdt blob at 0xbee8f640
> > > > Working FDT set to bee8f640
> > > > Failed to reserve memory for fdt at 0xbee8f640
> > > > FDT creation failed! hanging...### ERROR ### Please RESET the board ###
> > > Looks like the FDT is part of the region reserved for U-boot image
> > > post relocation. That region is marked as no-overwrite, meaning any
> > > other allocation attempt to the region will fail. Please check the
> > > relevant log below. The relevant code is in
> > > boot/image-fdt.c:boot_relocate_fdt(). The code gets exercised because
> > > fdt_high and initrd_high are being set to all ones. This was working
> > > in 2025.07 simply because the function call's return value was not
> > > being checked.
> > 
> > Thanks for the troubleshooting. I confirm that just removing that line
> > fixes the problem.
> > 
> > TBH I don't understand what the right thing to do here is, especially
> > whether copying the FDT a second time is the right thing to do here, so
> > anyone else taking a look is still appreciated. I *think* it should be safe?
> 
> I am not sure what is the correct thing to do here. Like I mentioned
> in my previous reply, this was working simply because the return value
> of the lmb allocation request was not being checked, which is
> definitely not the correct thing to do.
> 
> I see that the setting of fdt_high for the platform was introduced
> through 52b984369fde ("riscv: qemu: support booting Linux"). This
> commit is a good seven years old. And I am not aware of the context
> for setting this value, which seems to be discouraged as per the
> documentation.
> 
> @Lukas, would removing the setting of fdt_high and initrd_high cause
> any issues when booting the kernel from an FIT?

I do not quite remember the exact reasoning behind the change of the
patch. I suspect it was to get BBL running in a boot environment for
which it was not designed. Since OpenSBI has replaced it now, we should
no longer have these issues.

To confirm, I removed the lines setting fdt_high and initrd_high from
the latest u-boot master. Booting Linux from a FIT image worked without
any issues. This is using OpenSBI and the qemu-riscv64_smode_defconfig
u-boot configuration. I'd say this would therefore be the correct fix.

Best regards,
Lukas

> 
> -sughosh
> 
> > 
> > Vivian "dramforever" Wang
> >