[PATCH] riscv: qemu: Remove fdt_high default

Tom Rini trini at konsulko.com
Tue Sep 16 20:48:43 CEST 2025


On Mon, Sep 15, 2025 at 05:25:23PM -0700, E Shattow wrote:
> Hi Tom,  Add CC: Heinrich
> 
> On 9/15/25 07:32, Tom Rini wrote:
> > On Mon, Sep 15, 2025 at 07:45:49AM +0800, Vivian Wang wrote:
> > 
> >> Setting fdt_high to all ones is discouraged and does not appear to be
> >> useful for RISC-V QEMU. Moreover, it causes a boot failure when the FDT
> >> generated internally by QEMU is used while booting. Remove it to allow
> >> U-Boot to pick a suitable address and relocate the FDT.
> >>
> >> Closes: https://lore.kernel.org/u-boot/8397369a-9b0b-4798-9c30-3a81165657d6@iscas.ac.cn
> >> Signed-off-by: Vivian Wang <wangruikang at iscas.ac.cn>
> > 
> 
> > I'm very glad to see this finally and would like to see the rest of the
> > RISC-V platforms follow and do the same now.
> > 
> > Reviewed-by: Tom Rini <trini at konsulko.com>
> > 
> 
> When you say you would like the rest of the RISC-V platforms (to) follow
> and do the same;  What do you mean?  Heinrich and I were trying to
> figure this out off of something you said on IRC awhile back. I was
> taking a guess it was the qemu config (and this patch makes sense to me
> so I think that's part of it), but what else? Is that a reference to
> sifive-unleashed config fragment, are there others?
> 
> If you give us a detailed hint what we should be looking at it would go
> a long way and we can test / figure out the rest. Is initrd_high
> all-ones on your radar too?

The simple answer is that no platforms should ever set fdt_high=0xff...
nor initrd_high=0xff... by default. This tells U-Boot to never try and
relocate in memory these parts of the boot even when U-Boot knows that
they will overlap or are not correctly aligned. This in turn leads to
harder to debug failures at run time. Unfortunately RISC-V platforms
were introduced with these set and whatever checkpatch.pl check I had
missed them at the time (aside, most recently checkpatch.pl was missing
this in .env files, I fixed that today).

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20250916/4ee9b525/attachment.sig>


More information about the U-Boot mailing list