On Wed, 13 Aug 2025 at 14:20, Vivian Wang <wangruik...@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 <wangruik...@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?
-sughosh
>
> Vivian "dramforever" Wang
>
